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This report presents a software methodology for JPL Deep Space Network (DSN) data 
systems software implementations through transfer and delivery. The DSN Data Systems 
Software Methodology is compatible with and depends on DSN software methodology 
and also incorporates the characteristics of real-time program development in a DSN 
environment. The DSN Data Systems software implementation consists of a series cf six 
distinct phases: (a) planning and requirements, ( b ) design definition ; (c) design and 
production , (d) combined subsystem testing ; (e) acceptance test and transfer ; (f) opera- 
tion and maintenance . The unit (function) demonstration tests Ju. ,g the design and 
production phase will be planned early in the design definition phase. Each demonstra- 
tion will serve as a significant milestone and will show an increased program capability . 
An Independent Group (IG) is responsible for verification and validation of the DSN 
Data Systems software during development phases. 

The DSN Data Systems Software Methodology is being applied to all development 
software provided for or by the DSN Data Systems Section in Mark IV where f here *’* 
a desire for reliability , maintainability , and usability within budget and schedule 
constraints. 


I. Introduction 

The Deep Space Network (DSN) Data Systems Software 
Methodology is to provide standard methods and policies for 
the orderly implementation and management of the DSN 
Data Systems software through transfer ard delivery. The 
DSN Data Systems Sof'ware Methodology is compatible 
with and depends on DSN software methodology standards 
(Ref. 1), and also incorporates the characteristics of real- 
time program development in a DSN environment. The over- 
view of the DSN Data Systems software development tech- 
niques are as follows: 


(1) The DSN Data Systems software implementation 
plan is a series of six distinct phases : 

(a) F .jiing and requirements 

(b) Design definition 

(c) Design e nd production 

( Combined subsystem testing 
Acceptar ' and transfer 
(f) Operations and maiii*ena ;ce. 
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Before the acceptance testing phase, combined sub- 
system testing will be performed. The combined 
subsystem test phase will demonstrate that: 

(a) That the program meets functional, performance, 
and interface requirements in its real-time environ- 
ment and 

(b) Proper concurrent oneration of combined sub- 
systems. 

(2) The unit (function) demonstration tests during the 
design and production phase will be planned early in 
the design definition phase and will appear on the 
detailed Work Breakdown Structure (WBS> Each 
demonstration thus: 

(a) Shows an increased program capability 

(b) Proves module compatibility 

(c) Serves as a significant milestone (quality and 
quantity) 

(d) Produces test plans and procedures which often 
become a part of the Software Test and Transfer 
Document (STT). 

(3) An Independent Group (IG) is responsible for veri- 
fication and validation of the software during devel- 
opment phases. 


il. Software Classification 

The extent to which DSN Data Systems software methods 
and management policies are applied to the implementation of 
an individual software program is dependent upon the classifi- 
cation of that software into one of three software classes. 

The individual software classes are defined as follows: 

(1 ) Class I -New operation software 

(2) Ctass 2 Modified operation software (new functu *»s 
added or major revisions) where implementation cost 
exceeds one-h?if man year or $25,000 

(3) Class 3 Modified operation software (corrections 
or minor revisions) where implementation cost is less 
than one-half man year or $25,000. 

Table 1 lists the implementation documentation require- 
ments that are applicable to the three software classes. 


III. Software Design and Development 
Process 

A. Implementation Phases 

This paragraph presents each phase of the software design 
and development process. It identifies all of the responsible 
people, their function and it relates to each phase of the 
process, the products that will be generated, and the moni- 
toring, reviews, and control involved. Figure 1 summarizes 
the DSN Data System Software Management and Imple- 
mentation Plan. 

The phases of DSN Data Systems software implementation 
involve: 

(1) Planning and requirements 

(2) Design definition 

(3) Design and production 

(4) DSN Data Systems combined subsystem testing 

(5) Acceptance test and transfer 

(6) Operations and maintenance. 

B. Program Language 

Coding of the software design is performed using a standard 
high-level language approved for real-time and nonreal-time 
programs. The HAL/S language is a currently approved lan- 
guage used for all new minicomputer subsystem software 
development. The PL/M language is a currently approved 
language used for all Control and Computation Module (CCM) 
subsystem soft ware/ firm ware. 

The use of inherited code is not subject to the constraints 
and does not require a waiver to use an existing language. 

C. Milestones 

Based on the activities ^najor v_ cuments, design and test 
reviews) discussed in Paragraph III. A., eight major milestones 
are established which allow the overall software implementa- 
tion project to be planned and its in-progress development to 
be monitored. The milestones, in order of occurrence, are as 
follows: 

(1) Software Requirements Document (SRD) approved 
and DSN Level D review completed 

(2) Project Data Flow and Interface Design Document 
(LFD) approved 
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(3) Software Definition Document (SDD), Preliminary 
Software Operator's Manual (PSOM). and Develop* 
raent Test Plan (DTP) approved and architectural 
design review (Level E) completed 

(4) Final demonstration test review completed 

(5) Combined Subsystem Test (CST) review and pre- 
acceptance test review completed. Combined Sub- 
system Test Plan and Test Procedure (CTT) approved 

(6) Software Operator's Manual (SOM) approved 

(7) Soft waie Specification Document (SSD) approved 

(8) Software Test and Transfer (STT) Document 
approved. Transfer Agreement signed, deliverable 
transfer red to Operations. 

D. Reviews 

Technical reviews are required to assess the technical 
quality and progress of the development during DSN Data 
Systems Section software implementation process. Reviews 
are held at the end of each implementation phase. These 
reviews are of two types: DSN Data Systems Section internal 
reviews and DSN formal review. The DSN formrl reviews are 
described in Ref. I . 

The reviews, in order of occurrence, are 3 s described ui the 
paragraphs which follow'. 

1. DSN subsystem function design review (Level D). The 
DSN formal Level D review for each subsystem's software and 
the common software shall be held at the end of software 
planning and requirements phase. 

2. Pfcer design review. The peer design review shall be held 
after the DSN formal Level D review, at the end of design 
definition phase, to allow for corrective action and before the 
DSN formal subsystem detail design (Level E) review. The 
DSN Data Systems peer design review procedure is shown in 
Figure 2 The p'er design review criteria shall include: 

(1) Requirement traceability 

(2) Architectural design 

( 3 ) Man machine interface 

(4) Testing factors 

(5) Management information 

(<>) Mar dwaic and software development systems 

The detailed review form is shown in Ref. I. Members of 
the peer design teams shall consist o! the following 


(1) Software Manager (Chairman) 

(2) Independent Group representative 

(3) Data flow and interface engineer 

(4) Combined subsystem testing engineer 

(5) Senio software engineer 

Also, the DSN subsystem engineer and operational repre- 
sentative participate in the peer review. 

3. DSN subsystem detail design review (Level E). The 
DSN formal Level E review fi each subsystem's software 
and the common software shall be held after the subsystem 
peer design review and before substantially entering the 
design and production phase. 

4. Unit (function) demonstration test renew. The unit 
(function) demonstration test review for each subsystem and 
the common software is held at the end of each demonstra- 
tion test during the design and production phase. 

The technical >up supervisor shall be responsible for 
calling the meeting and for assuring resolution of all open 
items. Members of review teams shall include the Software 
Manager and the cognizant development engineer and his/ 
her staff. The Independent Group common software engi- 
neer may also participate, if required. The review focuses 
primarily on: 

( 1 ) Performance against design. The review 

(a) Systematically lists all program parameters such 
as dat : queue. Input/Output (I/O) queues, buffer 
pool (released buffer), etc. 

(b) Creates boundary conditions for these parameters 
and systematically chocks (hat all cases are per- 
formed properly against design. 

(2) Functional performance against funconal retire- 
ment. The review 

(a) Systematically lists all program parameters and 
system parameters such as 1 200-bit -per -second 
line, error polynomial, etc. 

lb) Creates boundary conditions for these parameters 
with test dnver/othcr programs and checks syste- 
matically that all cases arc performed properly. 

(3) Tests (creates) all possible hardware failures and their 
error recoveries. Also tests all peak load where all 
interrupt signals occur simultaneously . 
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5. Final demonstration lest renew. The final demonstra- 
tion test renew (section internal) shall be held at the end of 
the design and production phase. 

4. Combined subsystem test review. The combined sub- 
system test review (section internal) shall be held at the end of 
the DSN Data Systems combined subsystem testing phase. 

7. DSN subsystem transfer to operations review (Level F) 
This formal DSN review is optional and is held normally only 
for subsystem transfers. 

E. Documentation 

Documentation is a baselined product of each of the soft- 
ware implementation phases, and is produced concurrently 
with the design and other implementation activities conducted 
in each phase. Typical outlines for documentation are shown 
in Refs. 1, 2. and 3. Table 2 summarizes the documents and 
their responsibility . 

F. Quality Control 

The Independent Group shall assure the traceability of 
software requirements through architectural design, design 
and production, integration combined subsystem test, and 
transfer. The Independent Group conducts and observes the 
pre-acceptance test and combined subsystem tests, and is a 
signatory to test reports. 

Before completion of the transfer of the software from 
implementation to operations, DSN Quality Assurance (QA) 
certifies the status of the SSD (including the code). Detailed 
DSN QA requirements and procedures are contained in Ref. ! . 

G. Configuration Management 

All documentation and software products are maintained 
under configuration control by Software Production Manage- 
ment and Control (SPMC). SPMC provides security, integrity, 
- * controlled access to material within its custody and 
enforces configuration management practices. 

The SRI). SDD, SSD. SOM. and STT arc subject (ulti- 
mately) to DSN configuration management. The TRA, DTP. 
PSOM, DFD. CTT, and SMP are DSN Data Systems Section 
project documents, and are subject to DSN Data Systems Sec 
tion change control only 

I. Section (internal) change control. The TRA. DTP. 
PSOM. DKD, CTT, and SMP are maintained under DSN Data 


Systems Section configuration control in SPMC files, and ace 
updated whenever a change request is approved. AH change 
requests need to be justified and need to be accompanied by 
the modified change pages reflecting the change at the same or 
lower level or detail as was included in the original approved 
document. 

2. DSN change control The SRD and SDD are not main- 
tained bey ond program transfer to operations. The SSD, SOM, 
and STT are separate as-built documents delivered along with 
the completed program and are maintained throughout the 
operational life of the program. Therefore, the SSD, SOM, and 
STT are subject to DSN change control procedures. 

Detailed DSN Configuration Management requirements and 
procedures are contained in Ref. I . 

3. Water. Deviations from the Software Management plan 
may appear in the SRD or through the waiver procedure. All 
approved waivers shall be formally documented by the SPMC. 

It Methodology art 

There are two main categories of computers used opera- 
tionally and for software development support: 

(1) minicomputers 

(2) CCM-based microprocessors. Minicomputer applica- 
tions arc intended to be developed on Intel MDS sys- 
tems and/or a CCM-based Development Work Station 
(DWS). The development tool summary is shown in 
Table 3. 


IV. DSN Data Systems Mark IV Software 
Implementation 

Over the last several years (1978-1^80), the DSN Data Sys- 
tems Ground Communication Group has employed software 
development techniques such as unit (function) demo tests, 
combined subsystem testing, etc., for developing reliable real- 
time software for the Ground Communication Facility (GCFV 
Nctwork Operation Control Center (NOCC) Reconfiguration 
Project (Ref. 4 and 5). 

The DSN Data Systems Section is playing a major role in 
the implementation of the Network Consolidation Project 
(NCP) (Ref. b and 7). (Referred to in this paper as the 
Mark IV A Implementation Project.) This software methodol- 
ogy applies to all development software in Mark 1VA provided 
for, or b\, the DSN Data Systems Section in the Mark IVA 
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era where there is a desire for refcaOitity, maintaina bility, and 
usability within budget and schedule constraints. 

As of mid- July 1982, all DSN Data Systems computer 
programs are in the architecture design phase or the design 
and production phase. Table 4 contains the software classifica- 


tions for Mark IV A Interim software. T abie 5 contains the 
software classification for the Mark IV A final software. 

The status of the DSN Data System software implementa- 
tion for the NCP wifi be described in a subsequent issue of the 
TDA Progress Report. 
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Propulsion Laboratory. Pasadena. California. September 1 , 1978. 
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tions and Data Acquisition Progress Report 42-63, pp. 150-153, Jet Propulsion 
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Software cbiflflr>ttoni 


DoOttMBt 

Prcduct for each program 

Clam 1 

dam 2* 

ami 3* 

SR D 

Software Requirement* Poquawt 

Yea 

Yes** 

Yea** 

SDD 

Software DtfttdhM Docunaot 

Yea 

Yea 

Yes*** 

PSOM 

Prehnumry Software Operator's Manual 

Yea 

Yes 

Yea 




(Redhne 

(Red** 




SOM) 

SOM) 

DTR 

Development Tatt Plan 

Yes 

Yes 

Yes 

SOM 

Software Operator's Manual 

Yea 

Yes 

Yea 

SSO 

Software Specification Document 

Yes 

Yea 

Yes 

STT 

Software Test and Transfer Document 

Yea 

Yea 

Yea 

TRA 

Test Requirements Analysis Report 

Yea 

If 

critical 

No 

* Existing Documents u pda tad fat Oanpt 
**ECR ♦ Softcost (Ref. 8) ■ SRD on Changes 




•••ECO+WBS 

- SDD on Changes 





Tabled 

Phase 

Document 

Responsibility 

Approved By 

Review By 

l 

SRD 

CDE 

DSN Line Mgrs (8 KM 3) 
S/W Mgr (Concur) 

IG 

2 

SDD 

CDE 

DSN Line Mgrs <810-13) 
S/W Mgr (Concur) 

IG 

2 

Preiun SOM 

CD! 

Supervisor. S/W Mgr 

IG 

2 

DTP 

CDE 

Supervisor. S/W Mgr 

IG 

3.4 

SOM 

CDF 

DSN line Mgrs (81 (M3) 

S/WMgi 

IG 

3.4 

SSD 

CDE 

DSN Line Mgrs (810*13) 


3. 4. 5 

STT 

CDE 

DSN Line Mgrs (8 KM 3) 

IG 

1. 2 

DED 

PaU How and 

Subsystem Eng Mgr 

S/W Mgr. CDFs 



Inter faces Eng 

Section Mgr 

IC/CST Eng 

2.3.4 

CTT 

CST Eng 

Integration Mgr 

S/W Mgr 




Sec: ton Mgr 

IG. TGSs, CDEs 

1. 2.3 

TRA 

IG 

CST Eng. Integration Mgr 

S/W Mgr 




Subsystem Eng Mgr 

CDEs 

1 

SMP 

S/W Mgr 

Section Mgr 

TGSs. CDEs, Cost Eng 


Integration Mgr 
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TMn3. OGVGtopcmnt Tool Summary 


Tool 

Phases 


Utilization 

Cost model 

I 

CDE/Supenrnor 

Schedule 

Word processor 

l, 2, 3,4, $ 

CDE.SPMC 

Documentation 

Work Breakdown Structure (WBS) 

2, 3*4,5 

CDE/Supervisor 

Scheduling and milestones 

Program Design Language (POL) 

2*, 3, 4, 5 

CDE.SPMCQA 

Documentation 

HAL/S 

3,4.5 

CDE 

Modcomp high-order language 

PL/M 

3,4,5 

CDE 

CCM S/W/ftrmware language 

Devetopmen Version Control System (DVCS) 

3,4,5 

CDE. SPMC.QA 

Version control 

Multipie terminal for software code 

3.4,5 

CDE/lmplementer 

Code development 

Anomaly Report System (ARS) 

3,4,5 

CDE, COE, IG 

Anomaly Reporting System 

Source Editor (SED) 

3.4.5 

CDE/lmplementer 

Modcomp Source Editor 

Assembler* 

3.4.5 

CDE/lmplementer 

Modcomp language 

Test generator* 

3. 4.5 

CDE/lmplementer 

Debugger 

•Option 


Tabled Software c lassfflc atkm for Mark IV A Interim softw are 


Subsystem 

Program 

S/W 

classification 

Code estimates 

(X 1000 line*) 

Command 

Deep Space Station (DSS) Command 
Modulator Assembl) (CMA) firmw-r* 

1 

1.6 


DSS Command Processor Assembly (CPA) 

2 

4.4 


Network Operation Control Center (NOCC) 
Command Real-Time Monitor (NCD) 

2 

0.2 

Tctemetr> 

DSS Telemetry Processor Assembly (DTM) 

2 

3.2 


NOCC Telemetr) Real-Time Monitor (NTM) 

2 

0.12 

NO<X Displav 

NOCC Display Subsystem (NDS) 

2 

2.4 


Video Assembly Processor (VAP) 

2 

0.3 

Common Software 

NOCC Common Software 

2 

56 
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Subsystem 

Program 

S/W 

classification 

Code estimates 
(X 1000 lines) 

Command 

Deep Space Communications Complex (DSCC) 
Command Processor Assembly (CPA) 

2 

0.8 


Network Operations Control Center (NOCC) 
Command Real-Time Monitor (NCD) 

2 

2.0 

Test Support 

DSCC Test Support Assembly (TSA) 

1 

31.7 


NOCC Test and Support Assembly (NTS) 

2 

12.0 

Antenna Mechanical 

DSCC Antenna Pointing Assembly (APA) 

1 

25.5 


DSCC Antenna Control Subassembly (ACS) 

1 

12.0 

Tracking 

DSCC Metric Data Assembly (MDAj 

2 

21.0 


NOCC Network Tracking Assembly (NTK) 

2 

25.0 

Radio Science 

DSCC Occulta tion Data Assembly (ODA) 

2 

16.1 

Monitor and Control 

DSCC Complex Monitor and Control (CMC) 

1 

40.0 


DSCC Link Monitor and Control (LMC) 

1 

35.0 


NOCC Monitor and Control (NMC) 

1 

20.0 

Telemetry 

DSCC Tc'emetry Processor Assembly (DTM) 

2 

20.0 


NOCC Telemetry Real-Time Monitor (NTM* 

2 

25.1 

Ground Communication 

DSCC Area Routing Assembly (ARA) 

1 

22.0 

Facility 

Central Communication Terminal (CCT) 

Error Correction and Switching Assembly (ECS) 

2 

12.0 


CCT Data Record Generator Assembly (DRG) 

2 

8.0 


CCT Central Communication Monitor (CCM) 

2 

7.2 


NOCC Network Communication Equipment (NCE) 

3 

8.0 

Display 

NOCC Display Subsystem (NDS) 

2 

0.3 


NOCC Video Assembly Processor (VAP) 

2 

0.3 

Network Support 

Star and VAX Interface Adapter (SV1A) 

1 

0.5 


Network Support Subsystem (NSS) Control 
Input/Output 

1 

10.0 


NSS Sequence of Events (SOE) 

1 

14.0 


NSS Standard and Limit (S&L) 

1 

16.0 


NSS System Performance Record (SPR) 

1 

16.0 

Common Software 

Functional Independent Data Module (FIDM), 
IEEE 488, STAR and FTS handler 

1 

4.0 


Local Area Network (LAN) RS-232 device handler 
for microprocess 

1 

0.8 
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SOFTWARE DESIGN DEFINITION 
(ARCHITECTURAL DESIGN PHASE) 


AND PRODUCTION 


MAJOR ACTIVITY BY 
C OGNIEANT DEVELOPMENT 
ENGINEER (COEV IMPLEMENTORS 


• GENE BATE S*D 

• WO. FOB VW 

• INHIBITED PGM CONSIDERATIONS 

• COST MOOd - CLASS C WBS 
INMAONETDATA base 

• REVIEW 


I •GENERATE SOD. WUM SOM AND DTP 
. • FUNCTIONS Of EACH PGM ANO DATA SMUCTURE 

• ARCHITECTURAL DESIGN ANO ORDER OF DEV. 

1 • MAWAACHtNE INTERFACE 

| • DATA ROW ANO tNTOFACE (INTERNAL AND BCT&NAO 

I DESIGN 

I • UNIT DUNCUOtD DEMO test PLAN and hah 
I flaUMMCNTS NEED OATES 

.• CLASS B WBS 
| • REVIEW 


• OP AH DESIGN, COOING AND TESTtN 

• UNIT (FUNCTION) OEMO ICSTS - 
OP INCREASING PGM RJNCVtOti 

• PMAL OGAO TEST AND BMPV 

• anomalies - WBS 

• GENERATE FINAL PtfiJM. SOM. 

• RfVEW ANO OtSTNBUTE SOM, SSO,$TT 


MAJOB ACTIVITY 
INDEPENDENT GRO'JP (IG> 


• VERIFY AND VALIDATE VW REQUWEMB^TS 
AGAINST FROVFDO 

• INITIATE A TEST WO. ANALYSIS REPOBT (TRA) 
•PARTICIPATE HV REVIEW FUNCTIONS AND 

INTERFACE WITH CD€b in formal scheouuo 
meetings. THE TGS» SHOULD SCHfOUU THESE 
meetings 


I • evaluate adequacy of yw ARCHITECTURE 
I OESIGNTOMEET ^LOCATED REQUIREMENTS 


OESIGN TO MEET ALLOCATED REQUIREMENTS 
PREPARE AND ISSUE FIRST DRAFT OF TRA 
REPORT 

PARTICIPATE IN REVIEW FUNCTIONS 


I •COMPLETE THE TRA AND SUPPORT C3 
| IN PREPARING CTT 
I • RftftEW PtfUM. CTT AND STT TO EN$U 

I 1 MEP FUNCTIONAL REQUIREMENTS 
• OBSERVE DEMO TESTS AND REVIEW TES 
• PARTIOPATE IN REVIEW FUNCTIONS 


MAJOR ACTIVITY BY 
COMBINED SUBSYSTEM 
TEST ENGINEER 


I •ESTABLISH THE TEST PHILOSOPHY FOR 
1 Hr W ANO VW 


• INITIATE COMfcNEO SUBSYSTEM 
TEST PLAN AND TEST PROCEDURE (CTT) 


• GENERATING OF Cn 


MAJOR ACTIVITY BY 
DATA HOW AND 
INTERFACES ENGINEER 


• PREPARE AND ISSUE PBEUM. OFD 

• COORDINATE INTERFACES 


.•GENERATE OFD 

«• ENSURE CONStSfENCY/MTOGRlTY OF 
• Kkift-nvaaft iuta a nw ai i 


B4D-TO-84D DATA FLOW FOR AU DSN SYSTEMS 


• ENSURE CON$ISm4CY/1NTBGtfTY 
. END-TO-tNO DATA HOW FOR AU 
I DSN SYSTEMS 


major activity by 

COMMON SOFTWARE 
ENGINEER 


UtOfNTlFY COMMON yw ELEMENTS 

{ • ESTABLISH AN IMPLEMENTATION PLAN FOR COMMON 
S W AND ASSOCIATED WBVi 
, ESTABLISH PRODUCTION PERSONN& THROUGH TGS* 


I • COOROMATE PREPARATION OF FUNCTIONAL SPEC. 
I OF NEW COMMON yW ELEMENT 
I* PROVIDE "USB” DOCUMENTATION AND TRAINING 
, AND SUPPORT SERVICE IN 9MC 


I •COORDINATE PtOOUCTlON OF COM 
| ANO GRfTONSIBU FOR FUNCTION! 
TESTING 


MAJOR ACTNITY FY 
SOFTWARE MANAGER 


• GENERA?! SOFTWARE MANAGEMENT PLAN (SMP) 

• MONITOR ANO MANAGE 


| • ASSURE PROPER RVTP SUBSYSTEM COORDINATION 
J IN SUPPORT Of SECTION INTERNAI/EXTEfelAl 
I S/WI/F TESTS,... PC 
1 • MONITOR ANO MANAGE 


• MONffOR ANO MANAGE {WBS, OM 

• COORDINAIE HA** RfQ. WITH H'W M 

• RESOLVE TECHNICAL CONHICTS 


SOFTWARE 

REQUIREMENTS 

DOCUMENT 



SOFTWARE 

DEFINITION 

DOCUMENT 


PRELIM 

software 

OPERATOR 

MANUAL 


DEVELOP TEST PLAN 


TEST REQUIREMENTS 
ANALYSIS 



DESIGN REVIEWS 
A DCNCUS FORMAL 


DSN. LEVEL D 


LEVEL E 
PEER 1DSN 


A DCNOTES SECTION 
INFORMAL 


PEER iDSh 

A 4 


DEMO TEST REVIEW 


A— -L 


GROUP INTERNAL 



APPLICABLE OM 

WBS 


I. SRO APPROVED AND OSN 
leva D REVIEW COMPLETED 
<COE) 


2. DFD APPROVED (DFE) 

3. SOD, PRELIM. SOM, OTP 
APPROVED AND architectural 
REVIEW COMF1 ~ED (CDE, TGS) 


kvi 


4. FINAL DEMI 
TESTS REVS? 
COMPUTED 


DEVELOPMENT TOOLS 
USED 


• SPMC JACQUARD WORD PROCESSOR 

• COST MOOIt - CLASS C W*S 
IN MADNCT DATA BASE 


• SPMC JACQUARD WORD PROaSSOi 

• CLASS! WBS IN MADNCT DATA USE 

• POL FOR TOP-LEVEL DESIGN (OPTIONAL) 


• POL • HAI/S • PI/M • OVCS 

• 7170 •WBS • ARS • SCO 

• JACQUARO WORD PROaSSOR 

• ASSEMBLER (IF REQUIRED) •STAR 


n 
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SOFTWARE OE5»N 
AND PRODUCTION 

1 SECTION 331 COMUNEO 

SUBSYSTEM TEST WG 

ACC9TANCI TCSTANO 
| TKANSrO TO OfOATION 

| OPERATION AND 

| maintenance 

JftETAH OCSIGN, COOMG AND TESTING 
; • UNIT JUNCTION) obro tests - PROVE BCMO 

OF INCREASING PGM FUNCTION CAMMUIY 

• FMAL DEMO TEST AND REVIEW 

• ANOMALIES - W B S 
GENERATING FI N*i PRRJM, SOM. SSD, Sn 
KVEW AND DISTRIBUTE SOM. $SO,$n 

• SUPPORT CST EGR AND IG FOR TESTING 

•demonstrate program meets srd and ofd IN 

REAL TIME ENVIRONMENT 

• demonstrate proper concurrent operation 

OF COMWNfO SUBSYSTEMS 

• FIX ANOMALIES - STT, CTT 

• REVISE Sn. SOM. SSO 

• SUBMIT PRttlM. SSO 4 PGM 
TOO A 

• ANOMALIES ~WBS,ARS 

| • RESPONSIBLE FOR THE OVERALL ACCEPTANCE 
TEST PROCESS AT OSS 11 
! • SUPPORT COE FOR ACCEPTANCE TESTING. 

SPT ANO SOAK TESTS 
1 • FIX ANOMALIES AND REVISED Sn 
1 A TRANSFER 

(•SUBMIT REVISED SSO 4 PGM TO QA 
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